Don't we still want to discourage use of Struct, while delaying its actual removal?

Probably, but I we need to think about how to do this: [discouraged = true]? :) IMO it's fine to do this PR until we figure out a better way here?

Sure. I guess the question is what are the real issues blocking widespread adoption of Any? Are we concerned that the hashing equivalent problems are going to make this unpalatable until resolved in protobuf libs? @lizan

If we're encouraging folks via warning messages and soon-to-be-crashes to migrate over but there's no examples and the canonical config isn't updated, I think we're doing it wrong.
note, haven't checked examples and docs, I'm trusting the comment thread on this.

I updated a lot of the docs for Any in #6025. I still have a TODO on the template YAML but I think the PR is fairly comprehensive.

@moderation so do you think we should move forward with the deprecation? Or give it 1 more cycle?

I'm a bit reluctant to weigh in as me wanting to remove deprecation notices due to my configs might be a habit only I have. Having a quick look there are only a few lingering uses of the envoy.http_connection_manager Struct left in the code base. The template YAML I mentioned and:

• test/config/utility.cc
• test/server/listener_manager_impl_test.cc
• test/integration/ads_integration_test.cc
• test/config/integration/server_xds.lds.yaml
• test/config/integration/server.yaml
• test/config/integration/server_unix_listener.yaml
• test/config/integration/google_com_proxy_port_0.v2.yaml

I'm sure expanding this out for the other Any changes will make this change larger. The impact of these deprecated configs is largely developer or builder facing and shouldn't impact end users.

I did notice that https://www.envoyproxy.io/learn/ needs updating - is that source in Github somewhere?

Lastly, we should make sure that projects that integrate with Envoy, particularly Istio, are well aware of the impending deprecations.

FWIW if we think the docs are fairly comprehensive and we can fix the rest by release, the other question is for a 1 year release cycle do we want to do 2 releases with warning and 2 releases with failure? If so I'd be inclined to drop this PR and just manually tweak the output of the deprecation script (I'm happy to take that on post-release) to handle the unusual cadence.

I guess the question is what are the real issues blocking widespread adoption of Any?

One issue is obviously #6252, seems Any made it difficult to generate consistent hashing for consolidating same ApiConfigSource, see #5744 as well.

FWIW if we think the docs are fairly comprehensive and we can fix the rest by release, the other question is for a 1 year release cycle do we want to do 2 releases with warning and 2 releases with failure? If so I'd be inclined to drop this PR and just manually tweak the output of the deprecation script (I'm happy to take that on post-release) to handle the unusual cadence.

+1, I'm trying to add more docs by the time of 1.10 release.

+1, I'm trying to add more docs by the time of 1.10 release.

I'm OK leaving this deprecated, though, I think fail by default is pretty harsh and we shouldn't do this? Also, if there are known hashing issues should we not deprecate until that is fixed?

I'm OK leaving this deprecated, though, I think fail by default is pretty harsh and we shouldn't do this? Also, if there are known hashing issues should we not deprecate until that is fixed?

I meant not fail by default, but leaving this deprecated until we fix the hashing issue.

@lizan the question I have is whether #6252 puts Any support in "not yet ready for widespread production use" territory. I know Istio uses it, but this has required some custom workarounds and were discovered by serious deep diving.

I'm good with removing deprecated if we feel #6252 makes us "not yet ready". If the concern is over blown and most folks can use Any today with no worries around hash stability, then we should mark it deprecated but add a whitelist exception to the fail-by-default IMHO.

@htuch we shipped 1.1 without Any. We could not identify the cause for CPU spikes when switching from Struct to Any even after making hashing deterministic in a short amount of time we had. This needs further investigation, but it's not a trivial correctness issue.

In that case, I'm good with the original PR and removing deprecate from the Struct fields. We can't deprecate without a production ready alternative in place.

Here are the details @kyessenov is referring to: istio/istio#12162 You'll see several attempts to fix it, with 'fixes' that worked in some contexts and not others, until finally we punted and turned off Any by default.

+1 let's merge this until Any is a production ready solution. I actually wonder if we should revert some of our config examples (cc @moderation) but I think we can leave it for now while we investigate.

Sounds good to me. We can leave examples for now.

Also before we deprecate, can we move the integration tests over? Good to have the new path be the default path covered.